Hi Tom,
One problem we find with the standard way of having the kflop pop up a message on the PC, is that the PC command system is completely blocked until the user responds. That is, no other thread can use the PC command protocol. Since our application is fairly complex, several things can be going on at the same time, in different threads, so here is what we are doing to work around this limitation. You might consider adding it to a future release. Our code added to PC-DSP.h: //SJH - additional old-style protocol
// Put up status message. Similar to message box, except no response required. String can be multi-line
// separated by \n chars. By convention, each line is prefixed with a punctuation char which hints at
// the type of message: !=error, #=warning, ?=operator action required (e.g. jogging), $=informational
#define PC_COMM_STATUS_MSG 50 // Persist+1=string (null terminated)
//SJH - new protocol: allows "non-blocking" messages and other long-running things.
// Runs in two phases:
// 1. works like old-style protocol, except that PC immediately sets the command back to zero, to
// acknowledge receipt of the command. This frees up the main command var for other threads.
// 2. when PC finally has a result, it sets the specified result field persist variable to a
// non-zero value.
// The kflop needs to initially wait with a short timeout for the command to be acknowledged. It then
// waits (with an arbitrary timeout) for the final result to come in the specified persist var.
// PC command is divided into bitfields:
#define PC_COMM_FIELD_COMMAND 0x000000FF // Command number (start at 100 for new protocol commands)
#define PC_COMM_SHIFT_COMMAND 0
#define PC_COMM_FIELD_THREAD 0x00000F00 // Originating thread (1-7) or 0 if old protocol. Can also use
// 8-15 for special purposes or if thread is unknown.
#define PC_COMM_SHIFT_THREAD 8
#define PC_COMM_FIELD_RESULT 0x000FF000 // A persist var number (0-199) which the PC sets non-zero when the
// command is finally complete. Kflop must initialize
// this var to 0 before sending the command. This var is not allowed
// to be 100-103, or >=200, otherwise the command is NAK'd.
#define PC_COMM_SHIFT_RESULT 12The status message command (50) we found to be rather useful, so you might want to add that "officially" as well. And BTW, is there a way to determine (in kflop c code) which thread number is executing the current code? Something like WhichThreadAmI(). For the new protocol, it would be handy to be able to determine this dynamically, since we have some shared code which can run in arbitrary threads.
Regards,
SJH |
|
